Recommendation 3 - Advocacy
Advocate for more streamlined data reporting solutions
Compliance reporting requirements are the primary drivers of data collection and management practices at the AIU, and program teams routinely identified these reporting processes among their top data-related pain points. While the AIU cannot entirely control the data reporting process, advocacy for the following actions at the state level could substantially reduce administrative overhead for reporting requirements, freeing additional staff capacity for program operations:
Consolidate State Portals to Reduce Points of Entry for Data Reporting
AIU program teams currently submit data through 14 separate state reporting portals. Because reporting requirements at the state level drive data system selection and design at the IU level, the varying data collection formats and requirements of each additional portal add successive layers of complexity to the AIU Data Ecosystem. A consolidated state portal unifying data formats and requirements across collection areas would simplify the needs of AIU systems, cutting down on data management time while improving reporting accuracy.
Improve State Data System Interoperability
Many AIU teams interact with multiple of the 14 state reporting portals that impact the AIU Data Ecosystem; a common pain point among them is lack of contextual awareness between state systems. That is, a program team may be obligated to report Student A in three different systems, but because the systems are not interconnected, the Student A must be entered separately in each system, often with demographic or program-participation data repeated across each data entry. Students’ demographics profiles, for example, are collected separately in PIMS, PASecureID, eData, PELICAN, PennData, MaxCapture, leading to (A) duplicated data entry efforts that could be reduced through secure data sharing between systems in the state’s digital ecosystem, and (B) potential for discrepancies, if this information is entered differently in different systems without a reconciliation process.
Develop Programmatic Data Submission Pathways
State reporting data entry costs considerable staff time for nearly every AIU program team with reporting obligations. While data reporting serves a critical function in the provision of public education and is a necessary element of operations, more can be done to improve the efficiency and accuracy of reporting processes. A taxonomy of four distinct reporting paradigms can be observed among existing collection portals:
- Manual Record-Level Data Entry - Each record must be individually key-entered into the reporting portal.
- Manual Batch Data Upload - Records can be bulk-submitted to the portal in a templated tabular format (e.g., .csv/.txt files), but uploads must be submitted manually through a user interface.
- Integrated Batch Data Upload - Local Operational Data Systems (e.g., a Student Information System) automatically package reportable data into the required format, and staff can trigger a batch upload on command, or the reporting portal otherwise makes a programmatic batch submission endpoint available to reporting parties, via API or SFTP, for example.
- Live/Transactional Data Submission - Local Operational Data Systems automatically sync each record with the state reporting repository, either on a live basis (a record is (re)submitted any time it is updated by a user) or on a schedule (e.g., nightly).
The above order descends from most (#1) to least (#4) costly in terms of staff time, and options #1-3 are well-represented across the 14 state reporting systems embedded in the AIU Data Ecosystem. For example…
The eData portal for reporting Adult Education program participation and outcomes requires individual-level data entry for each record (type #1);
The MaxCapture system for tracking Medicaid billing through the School-Based Access Program (SBAP), on the other hand, allows for bulk, template-based imports of key data resources, but lacks a programmatic endpoint, meaning users must manually compile and upload templates through a user interface (type #2);
PIMS, or the Pennsylvania Information Management System straddles types #2 and #3, with the help of third-party vendor systems, particularly Student Information Systems (SIS’s). That is, PIMS reports are submitted by staff through upload of templated flat files; however, many SIS’s include functionality to generate the PIMS templates directly from the interface, saving staff the time of manually compiling the data into the templated format (though further data validation is usually required prior to upload).
The project team did not encounter any AIU program teams interacting with a type #4 reporting portal.
AIU Advocacy Efforts should Encourage PDE to Build Type 3-4 Functionality for All Reporting Portals
Type #1 portals induce a ponderous reporting burden on program teams. No teams can use solely the reporting portal as their operational data system, due to data validation needs, portal access, and the need to retain files for future auditing; this means these teams must hand-enter each program record separately in multiple systems–often starting with collection of paper forms, which are manually entered into a local information system. This increases the risk of key-punch errors and incurs a great cost in terms of staff time that might be otherwise spent on program administration. Multiple teams indicated more students and families could be served if less time were spent manually delivering data from one system to another.
Converting these systems even to type #2 would liberate considerable staff time for reinvestment in program management. For current type #2 portals, development of programmatic endpoints (i.e, enabling automatic/scheduled batch uploads) would be a transformative change. Consider, for example, the portal for SBAP reporting: while it currently permits batch uploads of key data resources, each upload must be manually submitted through the user interface, meaning program staff must re-run exports from internal systems and upload to the portal again every time these key data resources–which are already updated in internal systems on a regular basis–change. An API- or SFTP-based template upload endpoint would enable program staff to schedule export/import workflows from the internal system of record, thereby saving substantial staff time and improving the frequency and timeliness of synchronization with state systems.
Adopt an Education Data Standard
Currently, most state reporting portals present distinct permutations of data format and data structure requirements. That is, the table and column definitions for student demographic information differ between, say, PIMS, DRC (for Keystone/PSSA pre-coding), PennData, PELICAN, and so on. Even if staff use a source system, such as a SIS, that stores the requisite data for each portal, they still must complete a distinct extract and load process for each destination reporting portal.
Separately, however, even if data collections were “standardized” on an existing portal’s templates–take PIMS collections, for example–the existing data definitions still would be idiosyncratic to state reporting uploads, rather than to LEA data operations. That is, the momentous effort vendors would be required to spend updating their applications to meet a new standard would yield benefits in terms of staff time for state reporting, but not much else.
For this reason, the state should adopt a more general and robust educational data standard, such as the Ed-Fi data model Alliance (n.d.), which, if local systems were to accommodate it, would not only reduce the state data reporting burden but would also make local systems (e.g. SIS’s, assessment platforms, etc.) better able to communicate with one another–an improvement with more direct positive impacts on program operations and, therefore, student learning.
Further, statewide adoption of an education data standard would facilitate smoother records transfer between programs and institutions. Data “lock-in” poses the primary challenge to information sharing, when students participate in multiple AIU programs or move from one institution to another, insofar as program B’s data system may not directly accommodate a records transfer from program A’s. As a result, either a considerable amount of staff time is consumed manually key-entering pre-transfer data into system B, or the student profile in system B simply starts from scratch, without the data context from program A (e.g., past program participation, evaluation results, etc.).
Beyond transfer of records, a common data standard would encourage better data resource sharing among programs and institutions. Consider an AIU-specific special education example: The Preschool Early Intervention (PEI) team recently collaborated with Data Services to create a data dashboard with key metrics for program participation and student services. While the underlying data resources represent the same type of information other special education programs collect across the division (e.g., student demographics, IEP dates, primary exceptionality information), the dashboard is not adaptable to other teams’ data because the data model of the source system (DocuShare) differs from that of other teams’ tracking systems (e.g., IEP Writer, custom MS Access databases, etc.). Were each system to comport with a common data standard, data resources like the PEI dashboard could be easily replicated for other program teams tracking the same data types.